上一篇文章[如何提升系統品質-Day17]品質量測工具-StyleCop提到了，如何透過StyleCop來確保程式碼符合設計規範。

但僅符合設計規範是不夠的，這一篇文章要介紹免費的靜態程式碼分析工具是FxCop，可以幫助我們快速的瞭解系統是否符合較好的設計原則，有哪一些原則可能是沒注意到的，有哪一些原則可能是可以加強的設計。

靜態程式碼分析的工具也需因地因時制宜，時間與範圍有限，應將資源投注在重點上。

[如何提升系統品質]系列文章連結
前言
FxCop其實跟Visual Studio較進階版本裡面的『程式碼分析』功能一樣，只是Visual Studio進階的版本直接內建在IDE裡面。這邊要介紹的原因是，就算沒有安裝Visual Studio，（例如CI server上）還是想對版本庫的程式碼進行靜態程式碼分析，我們還是可以透過FxCop的Console mode來對.exe與.dll檔，進行分析。

而這一篇文章，先以IDE工具為例，來方便讀者瞭解怎麼使用。

載點
1.Microsoft Windows SDK for Windows 7 and .NET Framework 4：
是的，您沒看錯，我也不知道為什麼FxCop的安裝檔要放在Windows SDK的工具裡面。我記得以前有獨立的安裝檔，但現在載點都失效了。（為了這篇介紹，我還是重新安裝了一次SDK）

2.安裝完SDK後，在路徑C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\FXCop\FxCopSetup.exe，可找到安裝檔。（要給其他人安裝，應該只需要這個安裝檔就夠了。）

3.版本：獨立的版本為FxCop 1.36，與Visual Studio整合的則為10.0，我猜版本號跳這麼大，應該是因為要跟Visual Studio 10.0綁在一起。

使用介紹
1.預設路徑在C:\Program Files (x86)\Microsoft FxCop 1.36\FxCop.exe，執行後我們點選Project=>Add Target：

2.加入要分析的dll檔，或是exe檔。這邊使用的範例一樣是PetShop的BLL專案。點選『Analyze』，便可看到分析結果。

3.根據rule的設定，會有嚴重層級的判定，較為嚴重的會判定為『錯誤』，輕微的則是『警告』。當點選違反規則的清單時，下方會出現分析的行號、原因，以及help reference。

當點選行號，則會使用Visual Studio開啟該檔該行，與一般的錯誤清單使用方式一樣。

當不瞭解為什麼這樣的code會違反rule時，可以點選Help的link，則會開啟MSDN網頁，針對該rule提供較詳細的解說。


[註]範例中違反的rule的MSDN reference

若其中有太多規則，因應系統我們想刪減檢查規則，或是針對某個特定分類的rule，例如全球化、效能、安全性來進行分析，可點選『Rules』的頁籤，將需要的rule打勾即可。

例如，method中都沒有使用到this，則performance rule會建議將此方法宣告成static，因為與instance無關，直接宣告成屬於類型的靜態方法，可以節省內存記憶體消耗。

FxCop用法就這麼簡單。

若您使用的Visaul Studio 2010為Premium版本以上，則可以直接在方案總管上，選擇『執行程式碼分析』

跑起來會久一點點，因為還會先全部建置一遍，再針對dll去作分析。（才叫做靜態程式碼分析）

在方案的屬性中，可以設定每一個專案，適用哪一些rule set。

而在每一個專案的屬性中，也可以設定該專案的程式碼分析規則有哪些，這些規則都可以複選。另外，可以選擇是否要在此專案建置時，同時執行程式碼分析。（方便，但我通常不用，一者是我很習慣告一段落就建置，再來是建置時分析程式碼要等待的時間太長）

同樣的，VS2010也有很棒的Addin: FxCop Runner，即使不是用Premium版本以上，也可以輕鬆的在VS2010上使用FxCop的功能來達到程式碼分析的目的。

CodePlex上也有針對FxCop有許多客製化rule或其他應用的open source project，請參考這邊

結論
善用工具，事半功倍。透過這些工具上面的輔助說明，可以讓我們學到更多好的設計，原則的存在一定有其原因，預防勝於治療，在發生問題之前學習，可以讓學習更有趣，讓自己更有價值，讓工作壓力更減輕。

MSDN reference
1.Managed 程式碼的程式碼分析警告，包含各項rule分類的說明。

2.使用程式碼分析進行 Managed 程式碼品質分析

3.OWASP的推薦